REMARKS 

The Office Action dated June 9, 2006 has been received and carefully noted. The 
following remarks are submitted as a full and complete response thereto. Claims 1, 2, 
and 4-38 are currently pending in the application and are respectfully submitted for 
consideration. 

In the Office Action, claims 1, 2, 4-12, 14 ? and 16-38 were rejected under 35 
U.S.C. § 102(b) as being anticipated by Beuk (U.S. Patent No. 5,774,673). The rejection 
is respectfully traversed for the reasons which follow. 

Claim 1, upon which claims 2-13 and 33-34 are dependent, recites a method for 
controlling data flow across a link. The method includes the steps of transmitting a 
packet request message from a first station to a second station, determining if the packet 
request message is valid, transmitting a request acknowledge message from the second 
station to the first station, and determining if the request acknowledge message is valid. 
The step of transmitting a packet request message further includes the step of generating 
the packet request message, which includes generating a request non-payload bit string 
corresponding to a pre-programmed packet request register. The packet request message 
and the request acknowledge message each include a control bit string, an identification 
bit string, and at least one parity bit. The control bit string identifies whether a frame is a 
control frame or a data frame. The identification bit string correlates the packet request 
message with a corresponding request acknowledge message. 
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Claim 14, upon which claims 15-27 and 35-36 are dependent, recites a data flow 
control method for controlling data transmitted across a high speed link. The method 
includes the step of transmitting a packet request message from a first station to a second 
station, said packet request message having a first identification number, a first control 
code group, and a first parity parameter associated therewith. The method further 
includes the step of storing the first identification number associated with the packet 
request message. The method also includes the step of transmitting a request 
acknowledge message from said second station to said first station, said request 
acknowledge message having a second identification number, a second control group, 
and a second parity parameter associated therewith. The method further includes the 
steps of determining if the first and second control groups are valid, determining if the 
second identification number matches the first identification number, and determining if 
the first and second parity parameters are valid. The first control group and the second 
control group are configured to identify whether a frame is a control frame or a data 
frame. The first identification number and second identification number are configured 
to correlate the packet request message with a corresponding request acknowledge 
message. 

Claim 28, upon which claims 29-32 and 37-38 are dependent, recites an apparatus 
for controlling data flow across a link. The apparatus includes a first transmitting unit for 
transmitting a packet request message from a first station to a second station, said packet 
request message including a first identification number, a first control code group, and a 
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first parity parameter associated therewith. The apparatus also includes a storage unit for 
storing the first identification number associated with the packet request message, and a 
second transmitting unit for transmitting a request acknowledge message from said 
second station to said first station, said request acknowledge message having second 
identification number, a second control group, and a second parity parameter associated 
therewith. The apparatus further includes at least one flow logic unit for determining if 
the first and second control groups are valid, determining if the second identification 
number matches the first identification number, and determining if the first and second 
parity parameters are valid. The first control group and the second control group are 
configured to identify whether a frame is a control frame or a data frame. The first 
identification number and second identification number are configured to correlate the 
packet request message with a corresponding request acknowledge message. 

The cited prior art reference of Beuk fails to disclose or suggest the elements of 
the claims, and therefore fails to provide the features discussed above. 

Beuk discloses a system for communicating between a dynamic group of 
apparatuses. The system allows an apparatus to establish communication between a local 
application and applications in other apparatuses. An active activation unit invites 
applications in other apparatuses to join by using a message sending unit to transmit a 
broadcast frame to all apparatuses which requests activation of the selected application. 
The broadcast frame specifies which application is being activated. The active activation 
unit then determines a communication channel which corresponds to the application and 
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the selected application, which is stored in storage, is executed by an execution unit. The 
broadcast frame is received by a message receiving unit in other apparatuses. A passive 
activation unit verifies whether the receiving apparatus has an application, which 
corresponds to the specified application and whether such an application needs to be 
activated (Col. 1, line 57 - Col. 3, line 25). 

Applicants respectfully submit that Beuk fails to disclose or suggest all of the 
elements of the present claims. Specifically, Beuk does not disclose or suggest "wherein 
said step of transmitting a packet request message further comprises the step of 
generating the packet request message, the step of generating the packet request message 
comprising generating a request non-payload bit string corresponding to a pre- 
programmed packet request register," as recited in claim 1 . Beuk also fails to disclose or 
suggest "wherein the packet request message and the request acknowledge message each 
include a control bit string, an identification bit string, and at least one parity bit," as 
recited in claim 1 . 

In the response to arguments section, the Office Action appears to take the 
position that the TYPE field of Beuk corresponds to "a request non-payload bit string 
corresponding to a pre-programmed packet request register," as recited in claim 1 . The 
Office Action also takes the position that the TYPE field of Beuk corresponds to the 
control bit string, identification bit string and at least one parity bit that are included in 
the packet request message and the request acknowledge message of the present 
invention. Applicants respectfully submit, however, that Beuk contains no disclosure 
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regarding the TYPE field being a request non-payload bit string corresponding to a pre- 
programmed packet request register, and a control bit string, identification bit string and 
at least one parity bit. 

Rather, Beuk merely discloses that various frames (acknowledgement frame, 
broadcast frame, group frame) include a TYPE field. Specifically, Beuk teaches that the 
"TYPE field comprises an A/M field and an B/G field. The A/M field is used to 
distinguish between an acknowledgment frame and a message frame. The B/G field is 
used to distinguish between the two types of message frames: a broadcast frame and a 
group frame" (Beuk, Column 12, lines 36-42). Beuk does not disclose or suggest that the 
TYPE field corresponds to any type of register. Beuk only discloses that the TYPE field 
includes entries which indicate whether it is an acknowldgement or message. Applicants 
respectfully submit that this disclosure does not correspond to the generating of a request 
non-payload bit string corresponding to a pre-programmed packet request register, as 
recited in the claims. 

Furthermore, the message receiving means of Beuk does not correspond to the 
pre-programmed packet request register of the present invention. Beuk discloses that the 
message receiving means 210 if for receiving a message frame (Beuk, Column 11, lines 
33-34). Further, Beuk discloses that "the message receiving means 210 only receives a 
group frame 630 if the channel field specifies a channel which has been locally activated 
(i.e. in the receiving apparatus) by the channel activation means 240" (Beuk, Column 12, 
lines 9-12). Beuk also discloses that the message receiving means 210 receives the 
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"activation request message 500 and verifies that the message has been received 
correctly. Beuk, however, fails to disclose or suggest that the message receiving means is 
pre-programmed and that it corresponds to the request non-payload bit string. 

Beuk, as mentioned above, merely discloses that the message receiving means 210 
is a component which may receive a group frame under certain circumstances. Beuk 
does not disclose or suggest that generating a packet request message includes generating 
a request non-payload bit string corresponding to a pre-programmed packet request 
register, as recited in the claims. In other words, according to the Office Action's 
rationale, Beuk allegedly discloses that the TYPE field of the frames 610 and 630 is 
generated in order to correspond to the message receiving means 210. However, Beuk 
contains no such disclosure. Beuk only discloses that the message receiving means 210, 
as suggested by its name, may receive message frames such as the group frame 630. 
Therefore, for at least the reasons discussed above, Beuk fails to disclose or suggest 
"wherein said step of transmitting a packet request message further comprises the step of 
generating the packet request message, the step of generating the packet request message 
comprising generating a request non-payload bit string corresponding to a pre- 
programmed packet request register," as recited in claim 1 . 

Applicants respectfully request that the rejection of claim 1 be withdrawn. Claims 
2, 4-13 and 33-34 are dependent upon claim 1. As such, claims 2, 4-14 and 33-34 should 
be allowed for at least their dependence upon claim 1, and for the specific limitations 
recited therein. 
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Furthermore, Beuk fails to disclose or suggest that the first identification number 
and the second identification number are configured to correlate the packet request 
message with a corresponding request acknowledge message, as recited in claims 14 and 
28. In one embodiment of the present invention, the packet request message and the 
request acknowledge message both include an identification string. 

According to an aspect of the invention, this identification string is used to identify 
and correlate a specific packet request message with the corresponding request 
acknowledge message. Through implementation of this correlation scheme, accurate 
flow control across a high speed link is generated and, therefore, queue or buffer 
management requirements are reduced at the receiving end (Specification, page 108, lines 
19-28). Applicants respectfully assert that Beuk fails to disclose or suggest that the 
identification strings are configured to correlate the packet request message with the 
corresponding request acknowledge message, as recited in the present claims. 

The Office Action takes the position that the identification bit string correlates the 
packet request message with a corresponding request acknowledge message "is 
anticipated by the channel field (first identification number) shown in group frame 630 
(packet request message) of figure 3 that is copied (correlates) to the channel field 
(second identification number) of acknowledgement frame 640 (request acknowledgment 
message) of figure 3 and that is used to filter acknowledgement messages as spoken of on 
column 4, lines 38-48 and column 12, lines 19-28" (Office Action, page 8, lines 15-22). 
Applicants respectfully disagree. Applicants respectfully assert that copying a first 
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identification number to another location does not produce a second identification 
number. Further, if the channel field is merely copied to a different location as disclosed 
in Beuk there would be no need to determine "if the second identification number 
matches the first identification number," as recited in claims 14 and 28. Applicants 
further assert that copying a field to another field is not the same as correlating a request 
message with an acknowledge message, as recited in the present claims. 

Additionally, Beuk specifically discloses that the channel field, included in the 
group frame 630, is used for identifying a communication channel. Each apparatus of 
Beuk includes channel activation means 240 for locally activating specific 
communication channels. The message sending means 200 only transmits a group frame 
630 if the channel field specifies a channel which has been locally activated by the 
channel activation means 240 (Beuk, Column 11, line 67 - Column 12, line 7). Beuk 
further discloses that "the acknowledgement frame 640 for acknowledging a group frame 
630 may comprise the same channel field as used for the group frame 630. In that case, 
the acknowledge sending means 220 will only transmit an acknowledgement frame, 
acknowledging the reception of the group frame, if the message receiving means 210 of 
Fig. 2 correctly receives a group frame, whose channel field specifies a locally activated 
channel. The acknowledge sending means 220 copies the channel identification from the 
channel field of the received group frame to the channel field of the acknowledgement 
frame" (Beuk, Column 12, lines 10-28). 
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Therefore, according to Beuk, the channel field is utilized to identify a 
communication channel. In addition, according to Beuk, a determination is made 
whether to transmit a group frame based on whether the channel field specifies a locally 
activated channel. However, Beuk does not disclose or suggest that the channel field is 
used to identify and correlate a specific request message with a corresponding 
acknowledgment message. Beuk merely discloses that the acknowledgment frame may 
include the same channel field as the group frame, and that the channel identification may 
be copied from the channel field of the received group frame to the channel field of the 
acknowledgment frame. The channel identification, as suggested by its name, is used to 
identify the communication channel used. Beuk does not disclose or suggest that the 
channel field or channel identification is used to correlate a specific request message with 
a corresponding acknowledgment message, as recited in the present claims. 

The Office Action acknowledges that the channel field of Beuk is used to identify 
a communication channel, but alleges that the channel field also "correlates a packet 
request message with a corresponding request acknowledge message" (Office Action, 
page 16, line 19 - page 17, line 2). The Office Action offers no rationale for this 
conclusion besides stating that the channel field is copied from the group frame 640 to 
the acknowledgment frame 640. However, as outlined above, the mere fact that Beuk 
discloses that the channel field may be copied from one location to another does not 
anticipate the limitation of "wherein the first identification number and the second 
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identification number are configured to correlate the packet request message with a 
corresponding request acknowledge message," as recited in claims 14 and 28. 

As a result, Applicants respectfully assert that Beuk fails to disclose or suggest at 
least this element of claims 14 and 28. In addition, claims 15-27 and 35-36 are dependent 
upon claim 14, while claims 29-32 and 37-38 are dependent upon claim 28. Therefore, 
claims 15-27, 35-36, 29-32 and 37-38 should be allowed for at least their dependence 
upon claims 14, and 28, respectively, and for the specific limitations recited therein. 

Claims 13 and 15 were rejected under 35 U.S.C. 103(a) as being unpatentable over 
Beuk in view of Meyer (U.S. Patent No. 6,61 1,495). The Office Action took the position 
that Beuk teaches all of the elements of claims 13 and 15, with the exception of the 
starting of a timer upon transmission of a packet request message and retransmitting the 
message if a predetermined period of time has passed. The Office Action then relies 
upon Meyer to cure the deficiency in Beuk. The rejection is respectfully traversed for the 
reasons which follow. 

Beuk is discussed above. Meyer discloses a system and method for improved data 
transfer in packet-switched communication networks. A sender receives an 
acknowledgement message indicating that the intended recipient received a data packet, 
and a retransmission timer is initialized with a value that compensates for the time lag 
between the transmission of a data packet by the sender and the receipt of an 
acknowledgement message. 



Applicants note that claim 13 is dependent upon claim 1, while claim 15 is 
dependent upon claim 14. Applicants respectfully submit that Meyer fails to cure the 
deficiencies in Beuk with respect to claims 1 and 14, as discussed above. Therefore, 
claims 13 and 15 should be found allowable for at least their dependence upon claims 1 
and 14, respectively, and for the specific limitations recited therein. 

Applicants respectfully submit that Beuk and Meyer, whether taken alone or in 
combination, fail to disclose or suggest all of the elements of the claimed invention. 
These distinctions are more than sufficient to render the claimed invention unanticipated 
and unobvious. It is therefore respectfully requested that all of claims 1, 2, and 4-38 be 
allowed, and this application passed to issue. 

If for any reason the Examiner determines that the application is not now in 
condition for allowance, it is respectfully requested that the Examiner contact, by 
telephone, the applicant's undersigned attorney at the indicated telephone number to 
arrange for an interview to expedite the disposition of this application. 
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In the event this paper is not being timely filed, the applicant respectfully petitions 
for an appropriate extension of time. Any fees for such an extension together with any 
additional fees may be charged to Counsel's Deposit Account 50-2222. 
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